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ABSTRACT 

The ESSOPE is a prototype front-end tool running 
on a Sun workstation and interfacing to ESOC’s 
MSSS spacecraft control system for the exchange 
of telecommand requests (to MSSS) and telemetry 
reports (from MSSS). ESSOPE combines an 
operations Planner-Scheduler, with a Schedule 
Execution Control function. Using an internal 
"model" of the spacecraft, the Planner generates a 
schedule based on utilisation requests for a variety 
of payload services by a community of Olympus 
users, and incorporating certain housekeeping 
operations. Conflicts based on operational 
constraints are automatically resolved, by 
employing one of several available strategies. The 
schedule is passed to the execution function which 
drives MSSS to perform it. When the schedule can 
no longer be met, either because the operator 
interferes (by delays or changes of requirements), 
or because ESSOPE has recognised some 
spacecraft anomalies, the Planner produces a 
modified schedule maintaining the on-going 
procedures as far as consistent with the new 
constraints or requirements. 

1. INTRODUCTION 

Many modem spacecraft, particularly those for 
science missions or experimental technology 
missions, are characterised by carrying payloads 
comprising a number of subsystems which will be 
employed on a variety of tasks or experiments. 
Recent examples of such ESA spacecraft are 
ERS-1, EURECA, and in the field of 
telecommunications, OLYMPUS. 

The operation of such a spacecraft is a complex 
undertaking; there are usually many constraints 
which have to be respected. Such constraints may 
prohibit the simultaneous or concurrent operation 
of two or more given payload subsystems in certain 
specific modes, for example because of interference 
or disturbances caused by one to another, or 
because of the shared use of some resource, e.g. a 


transponder, or a supply of electric power, or some 
available bandwidth in a downlink signal. 

Whereas it has been the traditional practice to 
operate spacecraft following rigidly pre-defined and 
pre-tested Flight Control (procedural) Timelines, 
and indeed this practice is generally continued for 
spacecraft platform operations, for complex 
missions such as those mentioned above a more 
flexible approach to defining the activities of 
payload operations is needed. Not only must the 
"on-board" constraints be respected, but also the 
temporal requirements of the satellite users, e.g. 
Principal Investigators or Experimenter Institutes, 
have to be accommodated. For example, an Earth 
observation satellite’s payload will be constrained 
to operate in one or another mode at different times 
according to the nature of the target areas (sea, 
land, ice...) which the satellite is passing over. As 
another example, users of a telecoms satellite may 
wish to schedule use of a given payload at times 
when they can have the use of specific ground 
station equipment for the performance of a 
communications experiment. 

Because of this need for flexibility in defining the 
activities of day-to-day operation, there is much 
interest in having the use of automated planning 
systems to generate operational timelines or 
schedules which define the actual activities in 
detail. Such systems can generate the sequences of 
telecommands which have to be uplinked to the 
payload at given times, or which alternatively will 
be loaded into an on-board Master Schedule for 
automatic on-board execution later when required. 

Automated "mission planning systems" have 
already been developed and put into daily operation 
for example for EURECA and ERS-1, where the 
schedules are prepared several hours in advance of 
their execution. 

It was decided to investigate the possibility of 
linking more closely the planning/scheduling 
function with a ground-based automatic schedule 


417 




Figure 1 : System Overview 


execution function. It was also decided to attempt 
to introduce an element of "reactive planning", i.e. 
fast revision of an existing currently executed 
schedule in the event of new constraints or user 
demands arising more or less in real time, or of 
on-board or other anomalies being detected during 
the operation and preventing some of the scheduled 
activities. 

In order to be able to demonstrate the concept of 
closely-coupled reactive planning and execution of 
operations, the Olympus geosynchronous 
telecommunications satellite was chosen as a "test 
case", and a demonstration system architecture was 
conceived which made use of existing ESOC 
infrastructure, namely the Multi-Mission Support 
System (MSSS) and ESOC’s real-time operations 
simulator of Olympus. The MSSS was augmented 
by the ESSOPE, which provides an "intelligent 
front-end" for the user, performing detailed 
schedule planning of the operations activities, and 
online step-by-step control of their execution. 

Figure 1 shows the combined configuration, and its 
operation is described later in this paper. But first 
follows a summary of the Olympus planning and 
execution problem domain, in order to give the 
reader an appreciation of the technical motivation 
for the choice of Olympus as the "test case" for the 
ESSOPE study. 

2. THE PROBLEM DOMAIN 

Note: The description given below relates to 
Olympus as it was being operated at the time when 
ESSOPE was being developed (1989-1991). In 
early 1991 Olympus suffered a solar array failure 
which has resulted in a significant reduction in the 
available power supplied to the payload. 


Olympus is a large geostationary 
telecommunications satellite which was launched in 
July 1989. It carries a multipurpose experimental 
payload to test future telecommunications flight 
hardware and provides an opportunity for 
communications and broadcasting experiments 
throughout Europe, and also in Canada. 

There are four quite separate payloads on 
Olympus-1, each with its own antennas: 

the Direct Broadcast Service (TVP) 

Payload 

the Specialised Services Payload (SSP) 

the 20/30 GHz Advanced Communications 

Payload (CMP) 

the Propagation Payload. 

The exploitation of these payloads in orbit is co- 
ordinated under an overall Olympus Utilisation 
Programme, which encompasses all aspects of the 
satellite’s use. 

The TVP payload operates at 18 GHz for uplink 
and 12 GHz downlink and there are two channels 
each with a pair of redundant high-power TWT 
amplifiers feeding twoseparately-steerable antennas 
which can beam down over different regions of 
Europe, Scandinavia and North Africa. A wide- 
beam uplink antenna can be accessed from 
anywhere in Europe. The TVP payload supports 
experiments in direct sound and TV broadcasting 
for domestic reception, education and training, and 
interactive information services, as well as 
technical tests of various kinds (TV standards, 
HDTV, antenna measurement techniques), for 
more than 20 user organisations. 

The Specialised Services Payload (SSP) offers 
bandwidths of 18 or 36 MHz, and operates in 
frequency bands between 12.5 - 19.3 GHz. Its 
antennas provide an array of five circular 
overlapping beams in a fixed pattern steerable over 
a very wide area. The SSP supports four up- and 
downlink signals which can be switched between 
the five beams, either in static mode, or 
dynamically allowing satellite-switched TDMA 
experiments to be made. 

Experiments cover a range of applications and 
technical tests, including SS-TDMA, tele- 
education, high-quality document image 
distribution, compressed video, news-gathering and 
frequency diversibility for many user organisations. 


418 





The Advanced Communications Payload (CMP) 
provides two 40 MHz bandwidth channels 
operating in the 30 GHz (uplink) and 20 GHz 
(downlink) regions. An alternative wideband 
capability of 700 MHz is supported. There are two 
spot beams independently steerable over a very 
wide area. Three output amplifiers provide one-for- 
two redundancy. 

A large range of technology and applications 
experiments are supported by the CMP for more 
than 30 user organisations. Worthy of special note 
is the Inter-Orbit Communications experiment in 
space data relay being successfully performed by 
ESA. This involves continuously steering on of the 
Olympus 20/30Ghz payload antennas to track and 
communicate with EURECA, ESA’s low-orbit 
Retrievable Carrier satellite, which has an orbit 
inclination of about 27° and a period of about 90 
minutes. 

The Propogation Payload just generates three signal 
beacons. Its operation is very simple, and was not 
sufficiently interesting to be considered in the 
ESSOPE study. 

On any typical day, many user institutes (here 
called "experimenters") are able to make use of 
Olympus services, however, not all can be 
accommodated simultaneously. ESA therefore 
performs scheduling of all operations, nominally 
about a week in advance. However, it quite often 
happens that adjustments to the schedule have to be 
made at quite short notice: a few hours is not 
uncommon. The scheduling is done using simple 
spreadsheet and database tools, with resource 
conflicts being resolved manually. In fact this 
system is quite adequate for normal weekly 
scheduling, but at the same time the Olympus 
scheduling problem is sufficiently complex to make 
it interesting as the "test case" for ESSOPE, 
especially for demonstration of "reactive planning" 
which cannot be achieved to anywhere near the 
same degree of real-time reaction by manual 
methods. 

Scheduling takes into account requests for specific 
Experiments (characterised by Experimenter, 
payload and its configuration) to be supported 
during given time windows. It must also take 
account of certain platform operations which can 
affect the availability or usability of certain payload 
configurations. 


Platform operations, which are essential to the 
health of the spacecraft, take priority over 
experiments which may conflict with them. Such 
platform operations include: Eclipse operation 
(reduced power available), station-keeping, attitude 
manoeuvres, and certain AOCS (Altitude/Orbit 
Control System) gyro calibration checks; the 
resource conflict created by the latter is not on- 
board, but on-ground: It keeps the spacecraft 

controller fully occupied for half an hour, so that 
he is not able to spend time configuring payloads 
ready for the next customer. 

Concerning payload resource constraints: Apart 
from the need to direct the required signal beams 
to the right places, and the need to allocate 
channels to users, some mutual resource constraints 
exist between payloads; for example, both the SSP 
and CMP share the 20/30 GHz transponders for 
some experiments. There are also power 
availability constraints to be respected, which 
become more severe in eclipse. 

Concerning payload configuration, the time to 
arrive at a desired new configuration will depend 
on what configuration was used immediately 
beforehand, and this must be taken into account by 
the scheduler. The number of intermediate states, 
through which the payload must be switched, 
directly affects the time to go from state A to a 
different state B. Usually each intermediate step is 
effected by a single telecommand (or block- 
command), and these must each be verified 
(verification delay 20-30 seconds per command) 
before proceeding to the next intermediate state. In 
certain cases longer delays and pauses have to be 
planned in the intermediate states. For example, 
the TWT amplifiers are normally kept warm either 
by active heating, or by the processing of signal 
traffic, but it is sometimes necessary to switch 
them off completely to conserve power. 
Subsequent pre-warmup to bring them back into 
use can take half an hour or so. 

However, because most of the possible payload 
reconfigurations can proceed at a rate limited only 
by the telecommand verification process on the 
ground (send command, await verification by 
MSSS on next arriving TM format... nominal delay 
18 seconds), and because such step-by-step 
operations (on the real Olympus, without ESSOPE) 
effectively tie up the spacecraft controller full-time, 
it the practice in those cases to avoid concurrent 
reconfiguration of more than one payload at a time. 
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This is one more "operating constraint" applied by 
ESSOPE, which is otherwise capable of scheduling 
and also executing reconfigurations of the payloads 
in parallel. In cases involving intermediate step 
delays, multiple payload reconfigurations actually 
do proceed in parallel. 

In addition to operating constraints imposed by the 
satellite itself, some ground-based factors have to 
be considered during scheduling, mainly related to 
the need to coordinate the activities of the 
experimenters in real time. This last point basically 
requires the ESA Olympus operations coordination 
function to contact experimenters by phone to 
ensure that they will be ready to use their allocated 
time slots, and that they do not transmit to 
Olympus outside those slots. This coordinator is 
also a schedulable resource; basically the available 
staffing allows phone calls to only one 
experimenter at a time. 

3. OPERATIONS WITH ESSOPE 

The ESSOPE has been developed to run on a SUN 
workstation, and is linked via a specially designed 
interface protocol to the MSSS software. The 
spacecraft operator is served through an ESSOPE 
user interface on the SUN, in addition to his 
normal MSSS operations interface 
screens/keyboard. 

ESSOPE provides two main operating functions to 
the user: A Planner/Scheduler which generates a 
schedule of Olympus operations, and a schedule 
implementation function ("Execution Control") 
which controls the execution of the schedule, 
coordinating it with the state of the spacecraft 
telemetry and with the activities of the spacecraft 
operator. The Execution Control function is served 
by the MSSS to perform the basic control functions 
on the spacecraft (simulator !). 

ESSOPE also provides appropriate knowledge 
acquisition functions, to configure it off-line (eg to 
allow the definition of procedure steps). These 
knowledge acquisition functions are not further 
described in this paper. For an exhaustive account 
of the design and functioning of ESSOPE, see 
(Refs. 1,2). 

ESSOPE Execution Control effectively takes over 
some of the low-level mechanical tasks of the 
spacecraft operator. Thus he no longer has to 
transcribe manually into MSSS the telecommands 


described in paper-based procedures or timelines; 
instead, ESSOPE reads these directly off the 
schedule generated by its planner/scheduler, and 
sends the appropriate telecommand requests to 
MSSS via the interface. In return, MSSS provides 
ESSOPE with reports confirming the uplink of the 
telecommands, and subsequently also their 
verification based on simple direct responses 
observed in the spacecraft telemetry. 

In normal MSSS operation (without ESSOPE), the 
operator is required to perform visual checks of 
spacecraft status at each step of the procedure, by 
viewing displayed groups of telemetry parameters 
on the MSSS screens. He has to compare the 
displayed values with an equivalent hardcopy sheet 
of required values, included in the standard 
procedures handbook: The "Flight Operations 
Plan". ESSOPE is able to make these additional 
checks automatically for him, at the same time 
advising him which MSSS displays to call up to 
monitor the same information. The required 
telemetry parameters for these checks are specified 
to MSSS by ESSOPE directly over the interface, 
and MSSS responds by sending regular messages 
containing the latest values, back to ESSOPE. 

MSSS performs continual limit checks on a large 
number of telemetry parameters, and when out-of- 
limits are detected, raises out-of-limit alarms on the 
MSSS user displays. When ESSOPE is in use, the 
out-of-limit information is sent to it by MSSS, and 
ESSOPE is able to perform some simple "first- 
level" evaluation of the anomaly, and propose to 
the operator an appropriate Contingency Recovery 
Procedure (CRP). 

The principal regions of the ESSOPE operator 
interface for Ops Execution Monitoring are shown 
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Figure 2: Execution User i/F 
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1 Figure 3: Planner Screen with Schedule Display 


schematically in Fig. 2. An overview of the 
schedule and of the steps of each active 
"procedure" in execution are displayed, with 
markers at the current position in each case, so the 
operator can follow the progress exactly. Note that 
a payload "procedure" in ESSOPE terms is not 
exactly equivalent to a Flight Control Procedure 
(FCP) in the traditional sense meaning a 
predefined, documented and validated procedure 
which the operator reads step-by-step out of a book 
on his console. A "procedure" for ESSOPE means 
a sequence of actions needed to change one of the 
payloads from one operating mode to another, in 
the context of the current schedule. This point is 
elaborated later under "Planning/Scheduling". 

The schedule display shows a planned timeline for 
each payload and for the platform. Each payload 
timeline defines a series of "procedures" for 
switching the payload configuration, chained 
together with the periods of steady-state payload 
operation where the actual experiments are 
performed. ESSOPE is not able to build all 
possible platform timelines, but a representative set 
of procedures for the platform can be generated. 

At any time, more than one procedure may be 
active concurrently, according to the progress along 
the individual timelines, of the schedule. The 
operator is no longer required to enter the required 
telecommands (or call up the TC sequences) 
manually on MSSS; instead, the appropriate 
commands for each procedure step are sent 
automatically into MSSS by ESSOPE. The 
operator can thus retain a higher-level view of the 
operation with less distraction, and still has at his 
disposal all standard MSSS information displays. 


Due to the modular architecture of the MSSS 
software, virtually no changes to it were necessary 
to accommodate ESSOPE, apart from the addition 
of a special interface server module. In fact the 
MSSS is essentially unaware that part of the 
operator’s normal (low-level) functions have been 
taken over by ESSOPE. 

4. PLANNING/SCHEDULING 

Fig 3 shows the schedule as displayed to the user. 
There are basically four parallel timelines, three for 
the payloads and one for the platform. 

The Planner/Scheduler generates schedule segments 
of 24 hours at a time, and can cover up to seven 
successive days. The starting state for each new 
day is automatically inherited from the final state at 
the end of the previous day. The operator specifies 
the requirements in the form of Platform 
Operations and times (these are considered 
immovable) , and Experimenter requests. The latter 
specify nominal start and finish times, and 
acceptable variations on these, as well as some 
parametric data affecting settings for the required 
payload configuration. 

Earlier in this paper, the concept of a "procedure" 
was briefly introduced. By "procedure" is meant a 
sequence of actions, or in the terminology of AI, 
"a goal-oriented plan" of actions which have to be 
performed in the context of the current schedule on 
one given hardware unit or subsystem, to change it 
from a starting state to the desired goal state. 

The planning of each timeline is derived from 
knowledge of an internal state-based model of the 
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relevant spacecraft subsystem. Each procedure in 
the timeline is composed of "Flight Procedure 
Steps" (FPS), which are placed at the appropriate 
points on the timeline. These are the smallest 
schedulable unit of activity, are rigidly-defined 
"mini-procedures", and are classified according to 
their function; a "state-to-state" FPS will move the 
state of a payload subsystem from one node to an 
adjacent node in the model’s state-space by sending 
telecommands. Other classes of FPS exist, eg a 
"wait" FPS can request and await some information 
from the operator, or can delay until some 
telemetiy parameter has acquired a given value. 
Each FPS is given a unique name to indicate its 
function, and the sequence of FPS names for each 
active procedure is displayed by the Execution user 
interface in a "procedure subwindow". 

The ESSOPE Planner/Scheduler builds the schedule 
in such a way that the timelines are only loosely- 
coordinated. And may be executed concurrently 
with no greater mutual synchronisation than is 
necessary. The scheduler respects all the 
operational constraints, and all conflicts discovered 
are automatically resolved by applying a number of 
strategies, eg shortening experiments or shifting 
them within specified time limits. Some of the 
factors which the conflict resolution takes account 
of are experiment priority. Experimenter priority, 
the proximity in time of experiments, the actual 
duration of the procedure required to switch each 
payload between the required modes. The user has 
the option to influence, during the scheduling 
process, the choice of strategy to be applied 
whenever there is a conflict, or he can leave the 
scheduling process to run automatically. Any 
redundant FPS are deleted. Production of a 
24-hour schedule segment is quite fast, being done 
in about 2 to 3 minutes on a Sun SPARC-2. 

The schedule is passed to the Execution controller 
as a set of parallel streams of FPS grouped into 
procedures, one stream per timeline. At the 
moment of execution, the operator has the choice 
of running any individual procedure in automatic 
mode, or in user-authorise mode where ESSOPE 
awaits his authorisation to commence each new 
procedure step. The schedule specifies an earliest 
and latest time for each FPS, and any FPS may be 
flagged with pre-conditions to block its execution, 
and post-conditions which it shall establish to affect 
the pre-conditions of other FPS (either subsequent 
FPS of its own thread or FPS of others); in this 


way a dynamic and elastic coordination between the 
timelines is achieved. 

5. REPLANNING 

It is possible that accumulated delays in execution 
of a given thread result in an inability to meet the 
final deadline for the next FPS. Or it may be 
necessary to abandon the execution of a particular 
thread or prematurely terminate the execution of an 
experiment because of the need to execute a 
Contingency Recovery Procedure to deal with a 
spacecraft anomoly. Or an Experimenter may 
announce at short notice that his requirements for 
his service that day have changed (maybe his 
equipment has broken down, for example). These 
situations lead to the need for a re-planning 
operation which is performed by the 
Planner/Scheduler; this is done while allowing the 
continuation of all active timelines which do not 
have to be stopped due to the problem in hand. 
The Planner/Scheduler passes the new version of 
the schedule (new timelines) to the Execution 
Controller which adopts it for continued operations. 
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